[backport camel-4.18.x] CAMEL-25694: camel-milo - fix write/call service failures being reported as success - #28368

TL;DR

The production change and the tests are the same as #27956. Two of the new tests do not compile on camel-4.18.x, and the upgrade-guide note is in the 4.17 to 4.18 section.

Blockers

• MiloClientProducerWriteFailureTest.java:68 calls super(new MiloClientConfiguration()). On camel-4.18.x the only MiloClientConnection constructor also takes a MonitorFilterConfiguration. The one-argument constructor came with CAMEL-25145, which is on main only. super(new MiloClientConfiguration(), new MonitorFilterConfiguration()) fixes it.
• SubscriptionManagerExceptionPropagationTest.java:155, :173 and :193 call new SubscriptionManager(config, executor, executor, 10_000). On camel-4.18.x the constructor is (MiloClientConfiguration, ScheduledExecutorService, long). The four-argument form came with CAMEL-25812 (#28111), which is on main only. new SubscriptionManager(new MiloClientConfiguration(), executor, 10_000) fixes it.

Other findings: 2

• The note === camel-milo - an awaited write, call or read that fails now fails the exchange is at camel-4x-upgrade-guide-4_18.adoc:1644, inside "Upgrading Camel 4.17 to 4.18", next to the 4.18.0 note about HEADER_AWAIT. The change ships in 4.18.6, so the note belongs under "Upgrading from 4.18.5 to 4.18.6" (line 14).
• The 4.18 guide on main does not have this note yet. It should go under "Upgrading from 4.18.5 to 4.18.6" there too. The main PR for the 4.22 note from #28367 can add this one as well.

The CI failure is this compile error. The build (17, false) job failed, and the JDK 21 job was cancelled after it. A re-run will not help until the tests are fixed. I expect the tests to pass after these two changes, but CI has not run them yet.

Reviewed with Claude Code on behalf of @davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

The davsclaus blockers from Oct 23 are all resolved in the Nov 2 commits:

• StubMiloClientConnection now calls super(new MiloClientConfiguration(), null) — correctly uses the two-argument constructor that exists on camel-4.18.x.
• SubscriptionManager is instantiated with new SubscriptionManager(new MiloClientConfiguration(), executor, 10_000) — the three-argument constructor that exists on camel-4.18.x.
• The upgrade guide note is under "Upgrading from 4.18.5 to 4.18.6" (line 14), not in the 4.17→4.18 section.

The production fix itself is correct: replacing handleAsync() with whenCompleteAsync() in the four SubscriptionManager methods preserves exceptional completions instead of converting them to normal null completions.

⚠️ Pre-fix test validation note — MiloClientProducerWriteFailureTest (testAwaitedWriteServiceFailurePropagatesAsException, testAwaitedCallServiceFailurePropagatesAsException) would not have failed before the fix. The StubMiloClientConnection overrides writeValue() and call() directly on MiloClientConnection, bypassing SubscriptionManager entirely. It returns the pre-arranged exceptional future straight to MiloClientProducer, which already had future.whenComplete((r, t) -> { if (t != null) setException(t); }) before this PR. These tests validate that MiloClientProducer wires exceptional futures to the exchange correctly — useful, but they were already passing before CAMEL-25694.

The actual pre-fix regression coverage comes from:

• SubscriptionManagerExceptionPropagationTest.testWhenCompleteAsyncPreservesExceptionalCompletion — directly tests the whenCompleteAsync vs handleAsync contract and fails before the fix.
• CallClientTest.testAwaitedCallReturnsResult — uses a real OPC-UA server through the full stack and fails before the fix (assertNotNull(result) would fail when handleAsync returns null).

The write path has no end-to-end integration test with a real server (only the stub-based isolation test), but the contract test covers the SubscriptionManager behaviour directly. Acceptable for a backport.

This review was generated by an AI agent, Hermès on behalf of @gnodet.